Playing Xconq
*************

This chapter is about how to play Xconq. Although Xconq supports a wide variety of games, they all have much in common, and it is these common features that will be described here. This chapter, along with any documentation for the game you're playing, should provide all the information you need to play and enjoy Xconq.

The term interface refers to the particular graphical user interface in use.  Examples include X11, curses, and Macintosh. Interfaces can vary radically from each other, since each is designed to be best suited for its environment. In practice though, interfaces all share the same commands, so that you don't learn to learn a whole new set when switching computers, and many of the displays are similar.

When reading this chapter, you should be aware that the term game is more precisely game design, since it is the set of rules and definitions of the game you want to play.  Since Xconq allows for many different kinds of game designs, much of the information in this chapter will be irrelevant to a particular game.  This will be indicated in the text by phrases like ``some games'' or by saying that a game ``may'' implement some concept or behavior.  You should learn what the game you're playing actually does in these cases. The names of the variables or tables to look at will often be mentioned in computer type.

Setting Up A Game
=================

To get started with Xconq, you have to select which game you want to play. The possibilities may be presented to you, or you may have to look in some sort of library to see what's available and then supply that name on a command line. If you don't do anything, then you will get a default game.

Some games require no additional setup; once loaded, you're ready to go. Others will require additional decisions, such as the size and shape of the playing area, whether exploration will be necessary, or whether the game is realtime.  These choices are variants of the game.  The exact set of variants is part of the game design, and the interface will (usually) tell you about them.

In addition, most games also give you a choice of which player is to play which side in a game, as well how many players can join in.  There are two kinds of players: humans, who have displays, and artificial intelligences or AIs for short, which are run by the computer. Some versions of Xconq may include more than one kind of AI; each type has a distinct name.  The AI named mplayer is always available.

An example might be a simulation of Europe ca 1900, named "la-belle-epoque", in which the sides might be ``England'', ``France'', ``Germany'', and ``Austria-Hungary'', and the players might be Joe on a Sun-4 named sun-lamp, Natalie on an HP machine named jaguar, and two of the mplayer AIs.  You can set Joe to play England, Natalie to play France, and the two AIs to play Germany and Austria-Hungary by using this command line:

     xconq -g la-belle-epoque -r Joe@sun-lamp:0.0 Natalie@jaguar:0.0 -e 2

Note that this is X11, so the :0.0 is the usual server and screen identification, while -r says not to open a display on the machine that is actually running the program.

Some game designs provide a way to even things up if the players are of vastly differing abilities.  In these designs, each player has an advantage that affects how much he or she gets to start with. Weaker players should get a higher advantage, so for instance a game with two players, of advantages 1 and 4, might give the advantage=4 player 8 cities while the advantage=1 player gets only 2.  This affects setup only; during the game all players are equal.  The variability of advantage also depends on the game; some may allows differences of 10 to 1 or more, while others, especially historically accurate scenarios, will have a fixed advantage that the designer has set for each side.

Once a trial player setup has been made, Xconq runs ``synthesis methods''.  The game design specifies the methods to use, which generate anything that was not explicitly spelled out; such as the initial location of countries, terrain features, and so forth.  As a player, you don't have to concern yourself much about synthesis methods, but you may get warnings or errors if a synthesis method is having difficulties.  A common case is where you ask for many players to be set up in a small world, and the set of constraints is too ``tight'' for an initial setup; you will get a warning that some players were given poor positions. Synthesis methods may also take a long time to run; for large worlds and lots of players, be prepared to wait.

When initialization and setup succeeds, Xconq will try to open up displays for every player that wanted one.  Exactly how this happens depends on the interface and networking capabilities of the version of Xconq you're using.  See the system-specific sections at the end of this chapter for more detail.  Once all the players are in, Xconq will start the game for real.

You may also get a warning that ``images were not found''.  This happens when the game design specifies the use of particular icons or patterns (collectively call images here), but they cannot be found anywhere by Xconq.  This is not fatal, because Xconq will use generic default images instead, but the display may be hard to understand. There are several possible reasons for images not to be found: 1) the game designer might have specified the use of particular images, but never defined them, 2) the library of images was not updated to include the needed images, or 3) the image library is not located where Xconq is looking.

Problems and Troubleshooting describes more of the errors and warnings that you may encounter, and what to do about them.

Starting Play
=============

What you'll first see depends entirely on the interface you're using. Typically there will be at least a map and a list of sides.  Help is available by typing `?' or clicking on a button that says ``Help''.  You can also just try to find your way around by experimentation.  (This is best done in a game by yourself, rather than in one with a lot of other people.)

The game proceeds as a sequence of turns.  During each turn, you and the other players get to move your units, which can be anything from cities to submarines to insects, depending on the game. In addition, there may be backdrop activities, such as changing seasons and weather, that go on all by themselves.  These typically happen at the beginning or end of a turn, not while players are moving their units.

Your exact goal depends on the game's scorekeepers.  Most games have at least one, some have several, and some have none.  There are many kinds of scorekeepers, so be sure you know and understand what they are before getting too far into a game!  If there are no scorekeepers at all, you can do whatever you like; any AIs playing in such a game will behave quite randomly.

A game may last anywhere from a few turns to many hundreds.  Again, this may be limited by the game design, or perhaps by the nature of the game. For instance, a game of oil empires might be forced to end when the world's oil supplies are exhausted...

Getting Help
============

Xconq includes extensive online help.  The keyboard command `?'  is available in all interfaces; some may also include a button or menu item that leads you to the help system.  Help information consists of a list of help nodes, each of which describes an aspect of the game or of Xconq in general.  There is usually a table of topics that you can select from, or else you can go forwards and backwards through the nodes.

Worlds and Areas
================

     Gallia est omnis divisa in partes tres [All Gaul is divided into three parts] -- JULIUS CAESAR

The Xconq ``world'' is always a sphere.  However, you only play on a piece of its surface, which is called an area.  Currently, there can only be one world and one area in a game; this may change in a future version of Xconq.

An area is divided into a grid pattern of cells.  Although squares with four or eight neighbors could be used (and were, in the very first version of Xconq), currently only a hexagon grid is available.  Each cell is therefore adjacent to six others, in the directions NW, NE, W, E, SW, and SE.  Areas have a width and height that are the number of cells across and up/down.  Although you can ask for areas down to 10x10 or less, or up to 1000x1000 or even more, the ideal default is typically around 60x30.  Larger areas consume vast quantities of memory, plus they're slow and unwieldy to play on; don't ask for them unless you have a lot of time and patience!

If the area's width matches the circumference of the world, it is a cylinder in shape.  The cylinder can be circumnavigated in an east-west direction.  This is what an 8x6 cylinder area might look like (periods are sea, + and ^ are land, # indicates edge cells):

     # # # # # # # #
      . . + + . . . .
     . . . + ^ . . .
      . . . . . . . .
     . . . . ^ . . .
      # # # # # # # #

Areas whose width is less than the world's circumference have a hexagonal shape.  This is an 8x7 hexagon:

        # # # # #
       # . + + . #
      # . . + ^ . #
     # . . + ^ . . #
      # . . . . . #
       # . . ^ . #
        # # # # #

The top and bottom rows of the cylinder shape, and all the sides of the hexagon shape, are called edge cells.  Your units may not enter them, unless leaving the area entirely, which some games allow.

The types of terrain you'll find in the world depends on the game design; typically there will be sea, land, mountains, swamp, and so forth, but more exotic games have been known to feature junkheaps, lava, and black holes as ``terrain''.

Terrain can cover an entire cell, be linear features passing through or between cells, or be a coating overlaying other terrain.  Cell terrain covers the entire cell uniformly, right out to its edges.

A border is the boundary between two adjacent cells; it has a distinct terrain type, such as ``river'' or ``beach''.  A connection is a narrow ribbon of terrain that reaches from the middle of one cell to the middle of an adjacent cell.  Like borders, connections are distinct types, for instance ``road'', ``railway'', or ``canal''.  Connections take precedence over borders and underlying cell terrain; in other words, if cell or border terrain is impassable, but there is a passable connection type, then the connection allows passage. Thus a connection can be usable as a bridge.  You may also find more than one type of connection or border, between two cells, such as both a road and a rail line.  They will be assumed to be side-by-side, so that units can use any connection that they like, and will be affected by all borders when crossing them.

A coating is like snow; it is a type that co-exists with cell terrain.  Coatings can change from turn to turn, varying in depth--and resultant effect on units.

Note that any single terrain type can only play one of these roles. This means you will never have river terrain that is both border and connection, nor will snow be both a coating and a cell type.

In some games, each cell has an elevation, which is basically elevation above sea level, but could be any range of values, as set by the game design.  The game design also defines the effect of elevation on movement, visibility, and weather.

A world can have people living in some or all of its cells. People belonging to a side report everything they see in their cell to their side.  Some types of units will cause the people's side to change to match their own.

A world can have named geographical features or just features, such as a bay, mountain, desert, or valley. Geographical features never have any direct effect on your game, but some interfaces may label features when drawing a map, or use them to help describe locations verbally, in phrases like "1 hex NW of Broken Hill".

The coordinate system is ``oblique'', with the X-axis in the usual horizontal, and the Y-axis vertical, but tilted to the right at a 60-degree angle.

           Y
       \  /
        \/
     ---------X
       / \
      /   \

The additional left-leaning axis is the x = - y line.

Units
=====

Units can be almost anything: adventurers, armies, balloons, bicycles, dragons, triremes, spiders, battleships, bridges, headquarters, cities.  Units move around, manufacture things, fight with other units, and possibly die.  They are the playing pieces of Xconq.

Units have a location, either in out in the open terrain of a cell, or inside some other unit.  In games that define connections, a unit may be on the connection rather than on the predominant terrain of the cell. (Think of a truck on a bridge.)  There may be more than one unit in the open in a given cell, up to a game-defined limit.  The collection of units sharing a cell is called a stack.  A unit inside another unit will be called an occupant in a transport, even if the ``transport'' is a type that can never move.

A unit's location may also include an altitude, expressed as its distance above the surface of the cell it is in.  Altitude affects combat and viewing abilities.

A unit either belongs to a side, or else it is considered independent.  Independent units do not do very much.  In more complex games, the unit's side merely represents the current ownership, and the unit may have a range of feelings towards each side, including its current one.  In those games, it is possible for one of your units to be a traitor!

Units can have a name, full name, a title, and a number, as appropriate to the situation.  The name is an ordinary name like ``Joe Schmoe'' or ``Cincinnati'', while the full name might be something like ``Joseph P. Schmoe''.  The title is a form of address such as ``Lord''.  The unit number, if used, is an ordinal that is maintained for each side and each unit type, so you can have both a ``1st national bank'' and a ``45th infantry division'' on your side.  Names and numbers are always optional, and can usually be changed at any time during the game.

Every unit starts out with a number of hit points or hp representing how much damage it can sustain before dying.  Certain types of units, such as armies and fleet of ships, have multiple parts, which means that damage to them reduces their effective size. Multi-part units can merge with and detach from each other.  Damaged units may recover their hp on their own, or else be repairable by explicit action, either by themselves or by another units (ships in port for example).

In addition to occupants, a unit can also carry supplies (food, fuel, treasure, etc), which are type of ``materials'' (see the next section).  Supplies are used up by movement, combat, and by just existing, and are gotten either by producing them or by transferring them from some other unit.  Some games start units out with lots of supplies, while in others you have to acquire them on your own.

What a unit can do at any one time depends on the action points or acp available to it.  Each sort of action - movement, construction, repair, etc - uses up at least one action point, and possibly more.  A unit with an acp of 0 can never do anything on its own, although other units can still manipulate it.  Also, not every type of unit can do every type of action; this is also defined by the game design.  Types of Actions lists all the types of actions that are possible in Xconq.

Units that engage in combat may accumulate combat experience or cxp for short.  Combat experience will increase with each fight, irrespective of outcome, up to a game-defined maximum.  An experienced unit will do better in combat, being both more effective in inflicting damage on opponents and at avoiding damage to itself.

You can lose a unit in many different ways: in combat, by running out of essential supplies, by being captured, by revolt, by garrisoning a captured unit, by leaving the world, or in accidents.  If a unit dies because of excessive damage (i.e. hp = 0), then in some games it will change into its wrecked type.  Wrecks are just normal units.  For instance, a city might be ``wrecked'' and become a town.  Occupants of dead or wrecked units will attempt to leave.  If they can't, then they will share the fate of their transport.  If an occupant can occupy a wrecked transport with no problem, then nothing will happen to it.

Materials
=========

In Xconq, materials are basically bulk inanimate stuffs, like food or fuel.  They are kept in units or in cells, up to limits defined by the game.  Materials may be provided as part of the initial game setup, or else produced by units and cells.  They are consumed by construction, movement, or merely in order to survive.  You can also move materials around from unit to unit.  Some games define laws of supply and demand, which will move materials for you, though not necessarily in the directions you would prefer!

In a few games, possession of a material type may figure into your score (your gold in a dungeon-type game, for instance).  In other games, there are no types of materials at all.  Sometimes materials exist only to constrain units' actions, such as fuel to prevent airplanes from straying too far from airports, and so you may not need to do much with the materials yourself.  The notes and help info for the particular game should explain this if so.

Sides
=====

Each player in Xconq runs a side.  The concept of ``side'' is somewhat abstract in Xconq; units in a game belong to sides, but the sides themselves are not attached to any particular unit.  Side often represent countries, but not invariably; they may be factions, governorships, or alliances, or just a convenient division of the game's units.

It is important to be clear about sides and players.  A side is a part of the simulated world, while a player is the actual real-world person or program that is playing the side.  You yourself are always the player, but in one game you may play the German side, and in another the Klingon side.  During a game, there will always be a player for each side, and vice versa.  The distinction is most important during setup and restoration of saved games, since you can choose which players go with which sides.

Each side can have a name and associated parts of speech, such as a noun for individuals on the side and an adjective to describe anything belonging to the side. A side may also have an emblem and one or more colors for displays to use.  Some game designs preset all this, while others let you personalize as desired.

Interaction Between Sides
-------------------------

In games with two players, your interaction is usually pretty simple, i.e. bash on each other.  In games with many players, some human, some mechanical, it is possible to have a variety of relationships, ranging from complete trust to complete hatred.

One thing you can do is to make your side be controlled by another side. This is basically a surrender that lets you stay in the game, because the controlling side can manipulate any of your units as if they were its own.  The controlling side also has the option of allowing or forbidding you to move your own units.  The relationship is strictly one-sided, and only the controlling side can release the controlled side.  (Note that this is a way to have several people play on a side; have one player run the controlling side and be helped by several other players running controlled sides, usually with agreed-upon responsibilities.)

A less extreme, but still very close, relationship is trust.  This is like a close ally - you can enter each other's transports, you share view data, and so forth.  Trust is a two-way relationship; both you and the other side each have to declare you want to trust the other.  You can do this at any time.  You can also, unilaterally, withdraw your trust in another side at any time.

Using Agreements
----------------

     Diplomacy is to do and say // The nastiest thing in the nicest way. -- ISAAC GOLDBERG (1938)

If you don't want to declare a special relationship with another side, but still want to make some sort of adhoc arrangement, you can create an agreement.  An agreement is a sort of generalized treaty; it consists of a number of terms agreed to by a number of signers, which are sides.  Agreements may be public or secret, and you can declare them to be enforced by Xconq if the terms are in a form it understands. An agreement that just says ``help each other out'' cannot be evaluated by the computer!

[Agreements are not completely implemented.]

Trade
-----

[Trade is not yet implemented.]

Tech Levels
-----------

In some game designs, technology and research are important.  These games give each side a set of tech levels (or just tech for short), one for each type of unit.  The tech level represents the technological knowledge needed to see, operate and build a type of unit. Tech levels never decrease, at least in the Xconq universe, and they can be increased by research and espionage.

There are several tech thresholds for a unit.  First there is tech-to-see, below which you will not even be aware of the existence of a unit (consider barbarians unable to see spy satellites passing overhead).  Then there is tech-to-use, which you must have in order to make the unit do any actions.  The tech-to-understand and tech-on-acquisition are points at which your side can increase its tech level just by owning a unit, and finally the tech-to-build is what you must have to create new units of the given type.

Side Classes
------------

In some games, several sides may be very similar to each other, while being very different from other sides in the same game.  For instance, the game might have several sides that are different tribes of barbarians, but they are more like each other than, say, Romans.  These similar sides can be given the same side class.  Units may then be restricted to be usable only by the sides in a particular class.  (Note that this is different from tech level, which allows units to be used by any side that has managed to acquire a sufficient tech level.)

Self-Units
----------

A self-unit is one that represents your whole side in some way. For instance, in a dungeon exploration game, your ``side'' might consist of an adventurer (you), your possessions, your followers, and perhaps more.  In such a case, if the adventurer dies or is captured, then the game should be over, at least for you.

Usually the self-unit will be set up by the game design, and all you have to do is to be aware that losing the self-unit permanently ends your participation in the game.  Some games might have ``self-unit resurrection'' (self-resurrects) which just means that if another type of unit is available when the current self-unit dies, then that another unit becomes your new self-unit.  For instance, admirals would leave their sinking flagship and board another ship, thus ``transferring the flag''.  (Admirals presumably being more valuable than captains, who are supposed go down with their ships!)  Some games may also allow you to change self-units manually (self-changeable).  In any, the game will define which types may be self-units (can-be-self).

Moving the Units
================

Once the first turn begins, you can begin looking at the display and moving your units.  Depending on the game design and startup options, you may or may not be moving simultaneously with the other players.  If not, then the players move one at a time, in the order that their sides are listed in any display.  Usually, you can choose freely which units to move next; you can move one a bit, switch to another, move it, then come back to the first one later, and so forth.  Some game designs may require that you move units in a specific order; perhaps all your aircraft must finish all their movement before any ships can move.

Turn Setup
----------

First, Xconq computes the number of action points available to each unit.  Each unit gets an increment of action points equal to its acp-per-turn.

The range of action points for a unit is normally 0 up to the value of acp-per-turn, but the parameters acp-min and acp-max may allow for an extended range.  You use this range by allowing a unit to accumulate extra action points by doing nothing for several turns, or to recover from an activity that used many action points all at once.  Think of this as a sort of temporary action ``debt''.  Units in debt at the beginning of a turn cannot act during that turn, and will continue to be inactive until they start a turn with an acp of 1 or more.

Types of Actions
----------------

Actions are the most basic kinds of things your units can do.  During play, the interface will usually give you capabilities that are easy to use, such as the ability to point at a destination and have the unit figure out which path to take to get there, but all such input eventually breaks down into sequences of actions.  Also, the rules of a game design are expressed in terms of allowed actions, their costs, and their consequences.  You will therefore find it useful to understand all the types of actions available.

Each type of action may have one or more ``arguments'' associated with it.  These are mentioned below as ``given'' values.

Movement:

  * Move to a given location. The unit being moved may be in a transport or out in the open, the destination is any location in the open (this will usually, but not always, be an adjacent cell), and may be at any altitude allowed for the unit.  (move-to)

  * Enter a given transport unit. The transport need not be on the same side as the entering unit. (enter)

Combat:

  * Attack a given unit. A successful attack causes damage and destruction to the unit being attacked. (attack)

  * Overrun a given location. The overrunning unit attempts to occupy the destination, capturing, ejecting, or eliminating any unfriendly unit present. (overrun)

  * Fire at a given unit, either using a given material as ammunition, or using any available material. (fire-at)

  * Fire into a given location, either using a given material as ammunition, or using any available material. (fire-into)

  * Attempt to capture a given unit.  If the attempt is successful, the unit changes side to match that of the capturing unit. Occupants will either escape, die, or be captured also. (capture)

  * Detonate at a given location. Detonation may damage any or all units in the vicinity of the detonation, and it may change terrain types as well. (detonate)

Construction:

  * Research a given unit type. This increases the tech level for the type being researched. (research)

  * Tool up to build a given unit type. (toolup)

  * Create a unit of the given type in a given unit. The unit will usually be incomplete. (create-in)

  * Create a unit of the given type at a given location. The unit will usually be incomplete. (create-at)

  * Build a given unit towards completion. (build)

  * Repair a given unit, restoring lost hp. (repair)

Unit Manipulation Group:

  * Disband a given unit, causing it to disappear. (disband)

  * Transfer part of a unit, either to another given unit, or to a new unit created by this action. (transfer-part)

  * Change side of a given unit to a given side. (change-side)

  * Change type of a given unit to a given type. (change-type)

Material Manipulation Group:

  * Produce a given quantity of a given material type. (produce)

  * Transfer a quantity of a given material type to a given unit. (transfer)

Terrain Manipulation Group:

  * Add terrain of a given type to a given location. (add-terrain)

  * Remove terrain of a given type from a given location. (remove-terrain)

  * Alter terrain to a given type at a given location. (alter-terrain)

Normally, you as the player and the side simply tell units to perform these actions themselves.  However, some games will allow the unit to cause the action to done as if another unit were doing the action.  For instance, a transport can pick up or drop off a non-moving unit.

Not all interfaces can be guaranteed to allow the most general forms of all these actions; you must consult the interface's documentation to find out which of these actions is available.

Movement
--------

Movement into a cell is easy to request--interfaces let you do this with a keystroke or mouse click--but each game design will have many rules constraining possible moves, depending both on the unit and the terrain it is moving over.  Certain kinds of terrain cost extra time to enter, leave, or cross.  The destination must usually be adjacent to the unit's current location, and may be at any altitude.

The other kind of movement action is to enter/leave a transport.  The only argument is the unit to enter, but again the constraints are complicated.  The transport must have sufficient space, both the entering unit and the transport must have sufficient mp and acp to complete the move, and the entering unit must be able to cross the intervening terrain.  The transport may be able to ferry the would-be occupant over any barriers; possibilities include no ferrying, ferrying only over the transport's terrain, ferrying over any borders, and ferrying over all terrain between the would-be occupant and the transport.

Although as with other actions, you use up action points to move, the cost of movement is based on movement points or mp.  A unit's speed determines the relationship between acp and mp; most of unit have a speed of 1.00, so for them acp and mp are the same. However, a unit with a speed of 4.50 and 2 acp will be able to do moves costing up to 4.50 * 2 = 9 mp.

In some games, you may be able to make one of your units leave the world entirely.  Sometimes this will seem like a good idea, perhaps to keep a trapped unit from falling into enemy hands, or because you win the game by leaving through a designated place.  To do this, you just direct your unit (which must already be at the edge of the world) to move into one of the cells along the edge.  If the departure is allowed, then the unit will simply vanish and be out of the game permanently.

In other games, you may be able to do a border slide.  This is where a unit can jump to a non-adjacent cell if the two cells have a border whose endpoints touch the starting and ending cell.  This is typically allowed in games so that ships can go through narrow straits without having to be ``between cells'' at any time.

Combat
------

     War is a matter of vital importance to the State; the province of life or death; the road to survival or ruin.  It is mandatory that it be thoroughly studied.  -- SUN TZU (ca 400 BC)

There are two basic kinds of combat, each with two versions.  A unit can either attack or overrun, meaning that it comes to grips with the enemy in some way, or it can fire, meaning that it keeps its position and throws rocks or whatever at a target.

Attack is directed at a particular unit, while overrun is a more complex action where the unit attempts to clear enough units from a given location so that it can move in.

A unit wishing to attack picks a position or unit to attack, Xconq computes the defender's response, then the outcome is computed.

(In future versions of Xconq, units may become locked in a ``battle'' and unable to do anything else until the battle is over or the unit has disengaged somehow.)

Firing can happen at long ranges, up to the range of a unit.  It may or may not involve using a specific material as ammunition; if the game gives you a choice, you will have to choose which, or else all possible types will be used.  You can fire at a specific unit if you can see it, otherwise you will have to fire into a cell; perhaps without knowing whether or not you're actually hitting anything in it.  Some units may also have a range-min and cannot fire at anything that is closer than that range.  (ICBMs and some kinds of artillery are limited in this way.)

Some units are capable of capturing other units, with a probability depending on the types of both units involved, and whether the unit being captured is independent or belongs to a side (capture-chance and independent-capture-chance).  If the capture attempt is successful, the capturer will move into the cell if possible, either as occupant or transport.  In some games, the capturer may be partially or even completely disbanded, to serve as the garrison. Capture may also occur as a side effect of a normal attack or overrun.

Detonation is a special kind of ``combat'' available to some units.  The action requires a location, either the unit's own position or a nearby cell.  Upon detonation, the detonating unit may lose some hp and even die (changing to its wrecked type, if defined, or else vanishing).  At the same time, it makes one hit on any units within its radius of effect.  Detonation may also be triggered automatically, such as by damage to the unit or even by another unit appearing nearby.

Research
--------

     Knowledge is power.  -- FRANCIS BACON (1597)

Research increases a side's tech for the unit type being researched.  Although you can only research a specific type of unit, some game designs allow for a crossover effect, where increases in the tech level for one type also increases the level in others.

You can have more than one researcher researching the same type, and thereby speed up your progress, but some games put a ceiling (tech-per-turn) on how much progress you can make in one turn.

Construction
------------

     We must be the great arsenal of democracy. -- FRANKLIN ROOSEVELT (1940)

Tooling up prepares a unit to create or construct the desired type.  As with research, game designs may allow a crossover effect for tooling.  Tooling may also decline gradually over time; this is called tooling attrition.  Many games do not require tooling up.

Actual construction of a unit happens in two steps; creation and building towards completion.  Most interfaces will also schedule research and toolup actions if a unit is told to build something that needs tech or tooling first.

Creation is the actual step of bringing a new unit into existence. If the new unit is complete, then it can be used immediately.  If not (which is usually the case), then the incomplete unit will exist and belong to your side, but be unable to do anything at all.  Incomplete transports cannot have any occupants, unless the occupants are types capable of helping complete the transport.  Incomplete units always have 1 hp, so they're vulnerable to attack.

Completion is achieved by doing build actions on the unit. Multiple units can all work on completing the same unit, but they must be sufficiently close, within a range defined by the game (usually the same or an adjacent cell).  In some games, there is a level of completion past which the unit will start working on itself automatically, and eventually become complete without any further action.

It is usually the case that the same unit will be able to both create and complete a unit, but if not, you will have to pay special attention to your construction plan, since an incomplete unit cannot act in any way.  You would have to either transport the incomplete unit to a type that can complete it, or the completing unit must come to the incomplete one.  Some games may allow the incomplete unit and its completer to be some distance apart, but the usual rule is that they must be in the same cell.

Note that multi-part units will be considered ``complete'' when just one of their parts is completed.  Most interfaces will have the builder continue growing the just-completed unit as long as it remains within construction range.

Repairing Units
---------------

Repair restores lost hit points to a unit.  Repairs can be done by the damaged unit itself, if it is not too badly damaged, or by another unit that is close enough.

Some games also feature automatic hit point recovery (hp-recovery), so you don't always have to remember to do explicit repair actions.

Disbanding Units
----------------

Disbanding is a voluntary loss of hp, ultimately resulting in the disappearance of the unit.  Most games only allow it for a few types of units.  Depending on the game, you may be able to disband the unit with one action, or you may need several before the unit actually goes away.

Units with occupants can disband, but only if the occupants are unaffected by the action.  If the unit would vanish or lose transport capacity, then the occupants must be disbanded or removed first.  (The interface may arrange to do this for you automatically.)

You always get back all of the disbanded unit's supplies, and they will be distributed to other units nearby.  In addition, the disbanded unit itself may become a source of materials, according to the table recycleable-material.  A percentage of the total material will become available after each action, if disbanding takes several actions to accomplish.

Transferring Unit Parts
-----------------------

In games where units can vary in size, you can shift one or more parts of a multi-part unit to another unit, or else create an entirely new unit.

You would use this action if, for instance, you wanted to detach a survey party from an exploring expedition, then rejoin later.

Changing Unit Side
------------------

In many games, you can give some of your units to another side.  You may also be able to take them from another side, if you control that side.

Unlike other actions, you may be able to cause a unit to change side without actually needing any action points, if the type is one that cannot act on its own.

Changing Unit Type
------------------

A few games allow you to change the type of a unit.

For instance, you might have this ability in a construction-oriented game, where you can take a town that has accumulated sufficient building materials and change it into a city.  Another possibility is that you have increased your technology level and are now able to transform a low-tech ship into a higher-tech ship.

Producing Materials
-------------------

Production is how a unit can produce a quantity of a material.

In many games, units already have a base production that is the amount of material that they produce automatically each turn.  This will often depend on the terrain, so that explorers in the forest will always ``produce'' enough water to drink each turn, but will start to use up their water supply when in the desert.

Transferring Materials
----------------------

Often there will be plenty of some type of material in the world, but the problem is getting it from the units that have it to the units that need it.  The transfer action is how you move material supply from one unit to another.

As with production, many games have some automatic transfers set up. For instance, games involving aircraft generally refuel them automatically whenever the aircraft has landed in a place with fuel to spare.  [Demands should be set by doctrine.]

Changing the Terrain
--------------------

In some games, units can add or remove borders, connections, or coatings, or may even be able to change the overall type of terrain in a cell.  The actions are add-terrain, remove-terrain, and alter-terrain, respectively.

The change happens immediately (for the sake of simplicity), but in practice, you may find that preparing for the change may take awhile. For instance, the unit executing the change might have to accumulate acp or materials required for the change.

Automation of Units and Sides
=============================

Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex, and, for that matter, not very realistic either.  Therefore, Xconq includes several levels of automation for human players.

The elements of automation are the task, the plan, the doctrine, and the strategy.  These are related to each other by goals.

Tasks are single activities of a unit that require one or more actions to accomplish.  Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport.  Most of the commands that you give while playing actually set up tasks rather than individual actions.

A plan is the unit's object that expresses its decided-upon behavior.  Elements of a plan include a type, possibly one or more goals, a task agenda, plus some assorted flags and properties. All units that can act and that are on a side will have a plan, while independent units that can do actions may have a plan that is preset by a scenario.  Plans primarily govern individual behavior, in many cases allowing the unit to act on its own, without needing any explicit direction from the player.

The doctrine is the set of parameters governing how the side will play and how its units should work generally.  For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.

The strategy and associated subobjects is what an AI uses to make all the decisions about what to do.  This object is not directly visible, unless the AI is acting as your assistant and the interface includes a display of its current strategy.

Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of player commands, which are different for each interface.

Using Doctrine
--------------

There is a doctrine for each type of unit on your side.  Several types may share a single doctrine, so that changes to it will affect all types equally.

  * wait-for-orders

     This is true if a unit should wait for explicit orders to be issued. If false, the unit should make up some sort of default plan and follow it.

  * construction-run

[more doctrine info]

Plans
-----

A unit's plan must be one of the types listed here.

  * None (none). Units with this type of plan do absolutely nothing.

  * Passive (passive). Units with a passive plan will execute any tasks they have been given, but will not add to the task agenda on their own. By default, if you are running the side by yourself, with no AI assistant, your units will have this type of plan.

  * Offensive (offense). Units with an offensive plan will look for favorable combat opportunities, usually within an area specified as their goal to hold.

  * Defensive (defense). Units with a defensive plan will seek to preserve the status quo.

  * Exploratory (explore). Exploratory units will seek to collect information about unknown parts of the world.

Tasks
-----

A task has several standard properties and may have additional properties specific to the task's type.  Xconq keeps track of how many times a task has been executed and how many times it has failed to execute a step correctly.  For example, a movement task to a distant location may need to execute 100 times, but it will only fail if the unit is actually blocked from moving.  If a task fails too many times, the plan or the AI may decide to remove the task from its agenda. If a task succeeds, it will always be removed.

Each task in a plan's task agenda must be one of the types listed here.

  * Do nothing (none).

  * Sentry (sentry). Stand sentry at the present location for a given number of turns.

  * Move in a direction (move-dir). Move in the given direction up to the given distance.

  * Move to a location (move-to). Move to within a given distance of the given location.

  * Occupy a unit (occupy). Move towards a given unit and attempt to enter it.

  * Pick up a unit (pickup). Move towards the given unit and wait for it to enter.

  * Build (build). Build a given number of units of a given type. This task will do research actions if necessary and possible, and toolup actions if necessary. Also, if there is an incomplete unit of the given type nearby, this task will complete it before creating a new unit.

  * Research (research). Do research to increase the tech for a given type up to a given level.

  * Hit a position (hit-position). Attempt to attack or fire on any units at the given position.

  * Hit a unit (hit-unit). Attempt to attack a given unit.

  * Capture a unit (capture). Attempt to capture any or all units at a given location.

  * Resupply (resupply). Replenish depleted supplies. This may be accomplished by production actions, moving to higher-productivity terrain, or by moving within supply range of a unit with the desired supplies.

  * Repair (repair). Repair damage to the given unit.

  * Do a single action (do-action).

Modes
=====

Interfaces to Xconq have typically two major modes governing how input will be handled; survey mode and move mode.  The purpose of these modes is to streamline the input and interaction process; they have no other consequence, and all functionality should be available in either mode.

In survey mode, you are basically just looking around the map.  Normal mouse clicks change the focus and perhaps scroll the map, but do not cause any units to do anything.

In move mode, a normal mouse click means to move the currently selected unit or units to the location of the click.

Standard Keyboard Commands
==========================

These commands should be available in all versions of Xconq. Additional commands may be defined for some interfaces; see the interface's documentation below for more details.

     [file commands.texi not included]

Backdrop Weather
================

Some games include environmental effects, which includes what we normally think of as weather; the temperature, clouds, wind, rainfall, snowfall, and snow cover on the ground.

The temperature falls in a range specified by the game, and may be computed in different ways depending on the game design, but typically depends on terrain, latitude, the severity of the seasons, and elevation.  Temperature may also vary randomly from turn to turn and cell to cell.  [describe effects of temperature on units]

A game may include clouds.  Clouds in Xconq are a single band, with a density, altitude of cloud bottom, and cloud height in each cell.  In this example side view below, o and O represent different densities of cloud, and - is the tops and bottoms, while ^ shows the ground.

         ----     --  -
       --oOOo --  OO  o
       OOoOOo oo--OO  -
     ^^--oOO- --OO--
       ^ --- ^^^--  ^^^^^
        ^^^^^   ^^^^

The chief effect of clouds is to prevent the viewing of units on the other side of the clouds.

A game may also include wind.  Wind has a force and a direction for each cell.  Wind affects the weather by causing clouds and storms to move around.  Certain unit types, such as sailing ships and balloons, may depend on the wind to be able to move around, and their speed will depend on the direction they take with respect to the wind.

Games may assert that the playing area represents part of a sphere, possibly tilted on its axis, and that poles and equator correspond to various latitudes.  If game allows temperatures to vary according to the time of year and the latitude, you will have seasons.

Backdrop Economy
================

The economy in Xconq is based upon materials.  Games that do not include any material types do not have any of the activities described in this section.

Material Consumption
--------------------

Units consume their supplies, both in the course of existence, and by motion/combat.  The rate depends on game and unit type; it consists of an overhead consumed each turn without fail, and consumption for each cell of movement.  The total is a max, not a sum, since units with a constant consumption rate are not likely to need additional supplies to move (consider foot soldiers who eat as much sitting around as they do walking).  Supplies may also be consumed for production and repair, again depending on game and unit types, but this consumption happens during the build phase.  Consumption is not affected by the situation of the consuming unit; armies in troop transports eat just as much as when in the field.

Material Movement
-----------------

Excess production is discarded, unless it can be unloaded into the producer's occupying units, or distributed to nearby units via supply lines.  Supply lines automatically exist between units that are close enough (as set by the game), and there is no need for explicit manipulation.  Supply line length depends on the game and the units on both ends, but is not affected by the intervening terrain.  Supply redistribution does not account for special needs anywhere; it just tries to utilize production excess.  The redistribution method is rather adhoc; units try to get rid of all their excess supply, and try to take up supply from other units within supply range.  Each direction is controlled independently, so for instance airplanes can get automatically refueled from a nearby city, but not from each other.  No unit will transfer all of its supply via supply lines.  Normally units in the same cell can exchange supplies, but some games can disable this behavior (out-length < 0), so that explicit transfer using the give and take commands is always necessary.

Backdrop Random Events
======================

Some games may include random events.  These are usually rare, but not always -- be sure you know the odds!

Accidents
---------

For some types of units in some types of terrain, there is a chance for it to have an accident that wrecks or eliminates the unit instantly.  This depends on both unit type and terrain type.  If the accident occurs, the unit is wrecked or vanishes along with all its occupants.  ``Wrecking'' and ``vanishing'' have separate probabilities. Occupants may survive wrecking, but never vanishing.

Attrition
---------

Attrition is ``slow death''; it takes away some number of hit points each time it occurs.  The rate of attrition depends on unit type and terrain or transport type.  Very low attrition rates may only take away one hp once in a while.

Revolts
-------

In a revolt, the unit changes sides spontaneously, perhaps to independence, perhaps to the side of a nearby unit.  Occupants will change over if possible, or else escape if possible, or else be killed. Any plans will be cancelled.

Surrenders
----------

Surrender is like revolt, but is always to the side of a nearby unit that is capable of attacking and/or capturing.  The capturing unit does not move.  Occupants of the surrendering unit also change over, escape, or die.

Scoring
=======

     Victory at all costs, victory in spite of all terror, victory however long and hard the road may be; for without victory there is no survival. -- WINSTON CHURCHILL (1940)

Different games can have different ways for players to win or lose. Some games may not have any scoring at all, while others have very complicated formulas.  You should be aware of the scoring in effect before you start to play a game!

In Xconq, a game's scorekeepers define how scoring is to be done.  Each scorekeeper tests some sort of condition and/or maintains a numeric score.  Scorekeepers also define when they run (perhaps only during certain turns or certain times within a turn) and which sides to look at.  Each scorekeeper is independent of the others, meaning it only takes one to decide if you win or lose.

In a game with many players, winning and losing can be a complicated issue; read the conditions carefully.  A scorekeeper can also decide to declare a game to be a draw and end it on the spot.

Once a side has won, it is out of the game.  Some scorekeepers only allow one winner, others allow several; in those cases, the scorekeeper will say what happens to the winning side's units.

Once a side has lost, it cannot be brought back into a game, even if another side tries to give it some more units or otherwise to reverse things.

It may also be possible to declare a draw, but all players still in a game have to agree to this.  While human players just have to enter the appropriate command (or answer appropriately when asking to quit the game), AIs may not always be willing to go along, particularly if they think they still have a chance to win.  If that happens, you must continue on.  (Some cowards have been known to abort the program or reboot the machine, in order to avoid an ignominious fate; unfortunately Xconq is merely a program and cannot prevent such slimy tricks.)

Finally, some games may record everybody's final scores into a file.

Last-Side-Wins Scorekeeper
--------------------------

The most common form of scoring in Xconq is called last-side-wins.  It is basically a fight to the death; any side that loses all of its units loses the game, and the last side with any units remaining is declared the winner.  It is possible that more than one side will lose all of its units at the same time, in which case Xconq declares a draw.

Since this would sometimes lead to bizarre stalemates (a submarine could hide at sea, thus preventing the side from losing, for instance), many games also define point values for units.  In such cases, last-side-wins makes a side lose when the sum of point values of all its units is zero, and the interface will have some way to display your current points.  By default, each unit of each type has a point value of 1; many games will define point values that apply to all units of the same type.  Some games may also define special point values for individual units.

Occupation Scorekeeper
----------------------

Occupation means that you have one of your own units in or near a fixed location or unit.

Unit Count/Sum Scorekeeper
--------------------------

This is a simple count of units, or else a summation of the values of some property, such as hit points.

Playing in Realtime
===================

Some game designs define limits on the realtime duration of a game.  For instance, the game might be set to end in one hour, a single turn might be limited to always last at most 2 minutes, or your side might be limited to 15 minutes of playing time, in the manner of a chess clock. If such limits are in effect, your display should be able to show you how much time you have left at any moment; pay attention!

When you run out of time, you are not automatically taken out of the game, but you can no longer do anything with your units.  Units that already have plans will continue to act on them.

The game design may give you a limited number of ``timeouts'' that you can call to stop the clock.  The timeout ends when you order a unit to do something.  Other sides will also be able to play while the clocks are not running.

You can see what the limits are by looking at the ``game design'' node of the online help.

Advanced Play
=============

This section covers additional features that may interest experienced players.

Mixing Game Modules
-------------------

Some interfaces (such as those using Unix-style command lines) may let you ask for more than one game design when starting up.  This is sometimes useful, for instance, if you want to play on the steppes world with a non-standard set of units; your command line might look like -g my-hacked-standard -g steppes.  You can also turn things around and load a file with your own changes after a complete game, as in -g gettysburg -g my-tweaks.

Be aware, however, that this cannot be guaranteed to work always, since the mixed-together game designs may have mutually conflicting definitions, or interfere with each other in subtle or not-so-subtle ways.  Just imagine the disaster if the world consists entirely of terrain that is instant death to your initial units!  Worse, Xconq may start up and run OK for awhile, then at the moment you're about to win---the object that you must capture simply cannot be captured by any unit at all.

So be careful about mixing designs!

Personalizing Your Side
-----------------------

Many games will pre-assign your side's name, emblem, enemies, and so forth.  However, many others allow you to change all that to suit your tastes.

The name is a proper noun such as ``Poland'', the noun is what you would call an individual, such as ``Pole'', the plural is for more than one, and <adj> is the adjective for things on that side, such as ``Polish''. The color scheme is a comma-separated list of color names, and <image name> names some sort of image file (like a bitmap).

The image may be of any size and combination of colors, with the caveat that it may not always work correctly.  For instance, two subtly different shades may get fused into a single solid color.  The emblem should also be small enough to fit reasonably into unit icons.  As a rule, most national flags will fit into a 7x5 rectangle, and coats of arms into a 7x9 region.  The color scheme should be useful by itself, when the unit icons are too small to fit the emblem.

Xconq will not allow you to have the same name, color, or emblem as another player in the same game.

The interface-specific side configuration uses the favored mechanism for that interface (if one is defined).  You should check with the interface documentation for more details.

Playing Hints
=============

This section is a collection of bits of information and advice derived from players' actual experience playing Xconq.

Player Alliances
----------------

Informal alliances frequently happen in games involving more than two people, so I have a few words of advice.  First, an alliance between two of the players is almost certain in a three-person game, and inevitably results in the ``odd man out'' being quickly defeated.  In four-person games, the alliances could be decided after looking at the map via a command-line option such as -v, so that one pair is not hopelessly separated.  Five or more players is going to be a free-for-all of formal and informal alliances.  Some scenarios are designed with a particular number of players in mind.

Advantage Rounding
------------------

When you set the advantage, Xconq multiplies the desired advantage with the normal number of starting units, then divides by the default advantage and ROUNDS DOWN.  This means that you might end up with a lot fewer units than you thought.  For instance, suppose that you have a game where each player starts with one large city and five towns, and this is considered to be an advantage of 10, because one large city is worth about as much as 5 towns.  Then if you select an advantage of 8, and your opponent selects 14 (because you're a better player perhaps), Xconq will give you 8/10 of the normal setup, which means four towns and NO large city.  Your opponent will get 14/10 of the setup, which works out to one large city and seven towns, which is really a 1 to 3 disparity, much more than the planned 4 to 7.  This is not a bug, just a limitation of the method.

Strategy
--------

The correct strategy for a game will depend on the game; some are deliberately designed to encourage or even force you to adopt a particular strategy.  In general however, classic principles of strategy apply perfectly to Xconq.  First, the words of an ancient master:

     Generally in war the best policy is to take a state intact; to ruin it is inferior to this.  -- SUN TZU

     Attack where he is unprepared; sally out when he does not expect you. -- SUN TZU

     There has never been a protracted war from which a country has benefited. -- SUN TZU

The most important consideration is to conceal your own forces and movements as much as possible.  Decoys and feints are worthwhile, but only if they don't draw critical strength away from your real purpose.

Don't rush to attack with weak forces.  Especially over long distances, the defender has the advantage.  Wait until you have assembled enough to take and hold a piece of territory, then allow some extra, just in case.

Have a plan, and have some contingency plans ready as well.

Be ready to take advantage of opportunities.

Problems and Troubleshooting
============================

This section describes some of the problems you might encounter, and what to do about them.

Errors and Warnings
-------------------

``Errors'' are fatal flaws.  Xconq must shut itself down in order to prevent a bad situation from getting worse.  You may be able to save the game, repair it, and restart it, but you must understand a good deal about GDL and about how Xconq works.

``Warnings'' are advice that something is amiss, but that there is no obvious reason to quit.

Any error or warning not listed below is almost certainly a bug, most likely in a game design, but maybe in Xconq, and should be reported as such.

Can't find module XXX anywhere
     This means that Xconq searched in the library locations it knows and found no modules named XXX.

Module XXX could not be opened
     This typically means that although the module was found, it could not be opened; for instance, it might have been read-protected.

Too many players
     Some game designs limit the number of players, and you asked for more than that.  Ask for fewer.

Requested advantage is too (low, high)
     The game design limits the range of advantages that you may request, and you went outside that range.

Only N of the requested displays opened
     (not the most useful message in the world - only document the "xxx could not be opened" message?)

Need at least one display to run
     Xconq is an interactive game; a game with no displays at all is sort of pointless, eh?

Images were not found
     A game design may not have had images defined for all types of units and terrain. Xconq will warn about this, then make up some (typically ugly) default images itself.  Actual game play will be unaffected.

XXX color is way off on display YYY
     It may be that a particular display and its software will not have set up a color that matches what was requested (this can happen in X, for instance).  This has no direct effect on game play, but some of the players may have difficulty if, say, their displays show several different terrain types as having the same color.

Memory exhausted
     Some Xconq games are exceedingly large and complex, and it is not unusual that they will need more than that available RAM or swap space.  This will typically occur during game setup, since Xconq preallocates nearly all of the space it will need. If you have no way to get more memory, you must choose a smaller game.  You can make a given game smaller by choosing the ``See All'' variant (no need to record views for each side) or by having fewer players and/or fewer AIs.  For instance, instead of playing against 7 AIs, you can play against one AI with an initial advantage of 7.

Can't open statistics file XXX
     (Obvious)

Can't open score file XXX
     (Obvious)

Sides have undesirable locations
     A game can specify how close and how far away each side should be from all the others, and the kind of terrain each will start on.  If the world is too small, or doesn't have the right kinds of terrain, then Xconq will warn about this.  The game will still play normally, but it may be grossly unfair, and if the sides start out hidden from each other, it may be a while until it becomes obvious how unfair it really is.

Cheating
--------

The standard builtin AI mplayer does not cheat; it always plays according to the same rules as you do.  This should be true of any AI in Xconq.  If you have evidence that would seem to indicate that any AI is using information it should not have, or is otherwise cheating, that is a bug and should be reported.  Note that sometimes the AI is smarter than you are, or moves more quickly; it may very well have spotted one of your units and disappeared again without you noticing.

Cheating by human players is possible, though not easy. For instance, a player could examine a saved game and learn all kinds of things, perhaps even starting up a separate game from it. As always, human ingenuity will defeat any purely technical defenses, and the best way to forestall cheaters is to refuse to play with them. If you suspect cheating, look at the game history and the final game statistics for things that seem suspicious.

The Game Library
================

One of Xconq's distinguishing features is its extensive game library. The variety can be rather confusing; which game should you be playing? To make matters worse, many of the games are still experimental, and not yet polished creations.

The following sections list the notable games in the library distributed with version 7.  The list is necessarily incomplete, and details of the games may change from release to release, so treat this only as a guide. Read the game's own instructions and notes for detailed information; if those are sketchy or missing, then it's most likely that the game is still being developed.

Generic Games
-------------

Xconq belongs to what might be called the ``Empire'' family of computer games; players each start with a small country and attempt to take over the world.  The available units, which players must build for themselves during the game, are generally modern military but somewhat abstract; armies, airplanes, battleships, and suchlike. The actual game designs in this category are just variations on the theme, being more/less complex or faster/slower-paced.

intro
     This is a simple game designed for newcomers to Xconq. It is not really very interesting once you've learned how to play.

standard
     The standard game is, well, the standard Xconq game.  It is by far the most developed, tested, and polished.  You can enjoy Xconq for years playing only this game and its variants.

classic
     The standard game of version 7 has been enhanced to take advantage of its new features, such as rivers and roads, but if you like the standard game of 5.x and want to continue with it, classic is a very close approximation.

crater-lake
     This is a classic of 5.x, so named because of the mountain ring with lake in the middle.  The real notable feature of this is the difficulty of mounting any offensive; this game has been fought to a stalemate time and time again.

old-empire
     Stroll down memory lane.  This is a workalike of the old simple Empire game, complete with balance, pacing, and other flaws. Compare how it plays versus the standard game; the flaws should be obvious.

earth-2deg, earth-1deg, earth-50km
     The entire Earth, at scales of 2 degrees/cell, 1 degree/cell, and 50km/cell, respectively.  This means that the areas are 180x64, 360x140, and 800x320 cells in size, which makes for games that are simply gigantic.

Ancient History
---------------

pelops
     If you're a fan of ancient history, try this version of the Peloponnesian War.  Although its game parameters need more work, you can get some idea of the scale of the conflict.  This is also a three-sided game, allowing for someone to play the Persians and perhaps win by exploiting the Athenians and Spartans.

rom-civ-war
     The Roman Civil War, played out on a very nice map of the Roman world.

European History
----------------

voyages
     This represents the Age of Discovery.

magellan
     Attempt to re-create Magellan's voyage around the world. Based on voyages.

1756, 1757
     These are renditions of the annual campaign seasons that made up the Seven Years' War.

1805
     Napoleon's Austrian campaign of 1805, of which the battle of Austerlitz proved to be the key action.

feb-1917, red-october
     The Russian revolution.

American History
----------------

gettysburg
     This is a set-piece version of the Battle of Gettysburg, at the brigade level with hourly turns. The setup is very detailed, but the mechanics simple, which unfortunately allows some rather bizarre-looking battles to develop.

WWII
----

The WWII games listed here are technical, detailed, and specialized to particular time periods or scenarios.

panzer
     This is a fast-paced tactical Eastern Front game, similar to the board games on the subject.  Features include strict line-of-sight (thus you can hide behind hills and trees), ranged fire, and a wide assortment of hardware.  It's not really very accurate, and it's stretching Xconq to use it for a tactical game, but great fun anyway.

magnusvew
     A large scenario based on a Panzerblitz(tm) board game scenario designed by Robert Harmon.

cherbourg, cobra, normandy
     These are all battalion-level games using the base game ww2-bn. The cherbourg scenario covers the capture of Cherbourg in the Normany campaign, while cobra is a reenactment of Operation Cobra, and normandy is the whole invasion!  While cherbourg is reasonably sized, the others are monster games that will need lots of memory and lots of time to play.

nw-europe
     This game ``zooms out'' to the division level, being about the entire NW Europe campaign.  Although you can open by landing in Normandy, you can try invading anywhere else if you like.

ww2-eur-42
     This is a theater-level simulation of WWII in Europe, starting in January 1942.  The Germans are on the ascendant everywhere, the Soviets hard-pressed, and the Americans only just getting involved.  The game has a lot of sides; either AIs have to play them or you'll need to round up a bunch of players.

ww2-38, ww2-39, ww2-42
     These are full global scenarios for advanced WWII.  Can they really be played as games?  Probably not -- but so what, we just want to scroll around and admire it all!

ww2s-eur-42, ww2s-42
     WWII again, but using the unit types and terrain of the standard game, and with only two sides, Axis and Allies.  It's not realistic enough for purists, but can certainly be exciting to play.

flattop
     This game is a somewhat abstract version of tactical naval combat. You have a force of carriers and battleships, plus a contingent of smaller vessels, and a similar opposing force somewhere out there.  Use your PBYs to find them, before their subs and destroyers get in to sink your capital ships.

coral-sea
     This is the battle of the Coral Sea, both land and sea, at the operations level.  Airplanes are simply part of carriers' combat abilities.

midway
     The Battle of Midway.

Empire-Building
---------------

The games in this category include more economic development than the combat oriented generic games.

empire
     An Xconqification of ``true'' or ``net'' Empire, which is a large and complex economic/military game.

modern
     Stan's conception of modern times.

Fantasy
-------

Although Xconq was never designed for the swords&sorcery genre, it turns out to be able to support some rather interesting games.

cave
     A basic dungeon game, where you wander around a maze and collect valuable items and battle various monsters.

u-midearth
     Tolkien's Middle Earth, what else?

ring-quest
     Middle Earth, but pursuing the One Ring specifically.

Science Fiction
---------------

Xconq was never really designed for outer-space games either, there are some fun if unrealistic designs.

galaxy
     A sort of generic outer space game with units mixed from various fictional universes.

starwars
     A moderately silly game.

tokyo, monster
     Inspired by a description of an old board called ``Crush Crumble and Chomp'', this is a game featuring one side as Godzilla and the other side as Tokyo. Hard to say whether it's more fun to play Godzilla and stomp on buildings, or to play the national guard and try to defeat him before Tokyo is entirely flattened!

     If you ask for just monster, you will get a randomized setup for this game.

Miscellaneous Games
-------------------

Some games just don't fit in any category.

beirut
     A somewhat disrespectful renditions of the goings-on in Beirut during the early 1980s.  Seven different sides, all fighting each other with tanks, death squads, and car bombs.

duel
     Two tanks, small area, no tricks.

hill
     Play the children's game ``King of the Hill''.  As an early tester said, ``Man, I figured you must have been on some really good drugs!''